	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<link rel="stylesheet" type="text/css" href="Styles/spsfbranding.css"/>				
						<title>Intention</title>
				<meta name="Description" content="" />
		<style type="text/css">

		.OH_TocResize
		{	
			top: 126px;
		}

		</style>
	</head>	
	<body class="primary-mtps-offline-document">
	<table height="93" width="100%" cellpadding="0" cellspacing="0" border="0"><tr><td style="height:93px; background-image: url('./_img/header_background.jpg'); background-repeat: repeat-x;"><img src="./_img/header_left.jpg" /></td><td valign="right" style="height:93px; background-image: url('./_img/header_background.jpg'); background-repeat: repeat-x; text-align: right;"><img src="./_img/header_right.jpg" /></td></tr></table>
		<div class="OH_topic">		  
		  <div class="OH_title">
			<table>
			  <tbody>
				<tr>
				  <td class="OH_tdTitleColumn">
					<div class="subHeading"><small>SharePoint Application Deployer</small></div><br />
					Intention
				  </td>
				  <td class="OH_tdLogoColumn">
				  				  </td>
				</tr>
			  </tbody>
			</table>
		  </div>
		</div>
		<div id="mainSection">
			<div id="mainBody">            
				<div class="introduction"><p></p></div>
				





        <h3>Intention for SharePoint Application Deployer</h3>
        
        Every SharePoint developer knows: One of the most critical tasks after the development of a SharePoint application is the deployment of the application to the several SharePoint farms. Because most environments at customers consist of DEVELOPMENT, TEST, INTEGRATION and PRODUCTION environments (or similar names) and cannot be accessed by the SharePoint developers themselves we need an approach which supports the following requirements:
        
        <h4>1. Requirement: Reusable approach for the deployment of WSPs</h4>
        Each SharePoint project must be deployed in the end to a separate SharePoint farm. The current approach of Visual Studio 2010 with the new deployment steps only works locally on your machine. But if the WSP solutions must be installed on a remote SharePoint farm, you need an automated script. This is needed in all your SharePoint projects and you don't want to think about this process in every new SharePoint project. You want to have one proven approach which can be used in all your SharePoint projects.

        <h4>2. Requirement : Fully automated process for deployment, upgrade and undeployment</h4>
        The deployment process in the past involved lot of manual tasks. Often this included deployment of WSP solutions to web applications, activation or deactivation of features, creation of mapped properties for search, creation of search scopes or any other configuration in SharePoint. This results in a not reproducible and  error prone manual process (and costs a lot of time and money).
        <br />
        To overcome this the deployment process must run fully automated. Somebody (typically in the operations department) should be able to start the deployment process and this should be the only manual step. After starting the process the deployment should run completely automated.

        <h4>3. Requirement : Fully configurable deployment </h4>
        Each deployment process is very similar  but different in minor aspects. In some projects we need IISReset, in some projects we need restart of SPUserCodeHost. Because of things like that our deployment process must be configurable in some areas, sometimes even different depending on the current environment (DEV, TEST, INT, PROD)
        
        <h4>4. Requirement : Parameterized process for different SharePoint environments</h4>
        Almost each SharePoint deployment process needs parameters because each SharePoint environment is different. The most obvious difference are the URLs of web applications. These URLs are needed during the deployment e.g. to deploy WSP files to dedicated web applications. All these URLs must be stored in the installation package and must be used depending on the current environment into which the package will be installed currently. 
        <br />
        If the URLs are not known during the creation of the installation package there must be a way to ask for these parameters at the beginning of the deployment process (e.g. with a dialog).

        <h4>5. Requirement : Fully integrated into the local build or Team Build</h4>
        If you build your Visual Studio 2010 SharePoint solution one major improvement is there since version 2010: the WSP files are created automatically. But: the files are spread around in your solution folder (normally bin/Debug). To deploy them to a SharePoint farm you must collect them together to create an installation package. 
        <br />
        The goal must be: building the SharePoint projects results in a final installation package in which all WSP files and additional deployment scripts are stored. This must work locally in your machine and more important also in a Team Build (e.g. in Team Foundation Server).

        <h4>5. Requirement : Detailed logging during the deployment</h4>
        In most of the cases the SharePoint developers have no access to the productive SharePoint farm (or they should not have). This means the developer delivers the installation packages and typically some guy at the operations department with less SharePoint knowledge must install the package. In case of errors during the deployment process the developer needs a detailed description about the reason for the failure.
        <br />
        So we need a detailed logging (e.g. into a file) during the deployment. This log file should be delivered back to the developer by the operations team in case of errors and the developer is able to fix the problems (in most of the cases wrong parameters, missing preconditions on the farm or unknown configuration of the target farm). The logfile should be written in a readable form to separate information message from errors and warnings.

        <h4>6. Requirement : Transparent and extendable approach</h4>
        Each deployment is very similar and very different in the same time: yes, we need to deploy WSP files, but very often we need to run additional tasks after the deployment. This can start from simple tasks like feature activation and could also end up in a long running operation e.g. to create sites and lists or activation of new features in hundreds of existing sites etc.
        <br />
        To allow this we need an approach which can be extend with custom actions, which can be executed with parameters for different environments.

        <h4>7. Requirement : Support for farm and sandboxed solutions</h4>
        Since SharePoint 2010 we additionally have the option to deploy wsp solution into a SharePoint site collection as sandboxed solutions. Although this is supported with PowerShell cmdlets (e.g. with Add-SPUserSolution) this must be supported by the deployment process, especially for the undeployment of sandboxed solutions and the restart of SPUserCodeHost.

        <h4>8. Requirement : Stable and predictable process</h4>
        Nothing is more problematic than one situation: The deployment worked partially and couldn't be completed. Some WSP solutions are deployed to the farm, some not. Some features are activated, some failed. The reasons could be different: missing permissions of the current user, wrong URLs for the deployment, typos in the deployment script, missing preconditions, failed deployment timer jobs etc.
        
        <h4>Conclusion</h4>
        To overcome this the deployment must be very stable. If timer jobs are taking longer than expected, the deployment script should wait until every job has finished. If WSP solution retraction failed (e.g. of concurrent file access), the script should wait and try again. The approach should run a pre-check before deployment (e.g. to check running timer jobs, permissions of the users, correct URLs etc.) and should immediately stop in case of errors.

		<br /><br /><img src="./_img/NewProject.jpg" /><br /><br />
		In the project template dialog under section "Guidance Packages -&gt; SPSF SharePoint SoftwareFactory" choose an appropriate project template e.g. "Simple SharePoint 2007 Application".
		
    
				</div>			
			</div>
							<div class="OH_feedbacklink"><hr size="1" />SharePoint Application Deployer, Version 2.1, see <a href="SPSF_OVERVIEW_800_LICENSE.html">License</a> for more information</div>
				<br />
					</body>
</html>

